1. Field of the Invention
The invention relates generally to voice messaging ("VM") system networks that support the Audio Messaging Interface Specification (AMIS) Analog Protocol. Such networks enable VM systems manufactured by different vendors to communicate in an open network (sometimes referred to herein as an "open access") environment.
More particularly, the invention relates to methods and apparatus for coordinating and controlling the execution of predefined VM system specific and/or protocol mandated processes in response to predefined signals which indicate the status of an AMIS Analog "Message Delivery Session". Each such session, as defined herein, is a single connection between voice message systems during which one or more messages, with accompanying protocol information, may be transmitted from an originator to an intended recipient.
An example of an event reported in the form of a status signal (sometimes referred to herein as an "exchange" status signal) that is processed by an originating system is a "destination busy" signal occurring during call set up; an example of an event reported in the form of status signal that is processed by both an originating and destination system is a "successful message delivery" signal; an example of an event reported in the form of status signal that is processed by a destination system is a signal indicating that the "originating system has hung up", etc. Again, as indicated hereinabove, each such event has a predefined status signal associated therewith in VM system networks in which the invention may be practiced.
The invention may be used in commercially available voice messaging system networks that support the AMIS Analog protocol, such as the Rolm.TM. PhoneMail.TM. VM system network. The invention is described herein, for the sake of illustration only, in the context of the PhoneMail VM system network.
2. Definitions
"Address"--A means by which the system and mailbox of a message originator and recipient are identified using the AMIS Analog Protocol. The form of the input from the originator identifying the intended recipient is locally defined. However, the address used in identifying the originator must have two parts: a System Number and a Mailbox ID.
"AMIS"--Audio Message Interchange Specification--A specification of the interaction between two systems for the purposes of exchanging voice messages via a common networking protocol. Unless otherwise indicated, it is used herein to reference the AMIS Analog Protocol described in the publication entitled "Audio Messaging Interchange Specification (AMIS)--Analog Protocol", Version 1, Issue 2, published in February, 1992, by the Information Industry Association, Washington, D.C.
"AMIS Analog Networking"--A networking scheme in which voice messages are transmitted in analog form between two systems and which involves the use of analog (DTMF) signals to convey protocol information. Messages and data are sent over switched or dedicated telephone lines.
"Dedicated Circuit"--A circuit, most often provided by a common carrier, which is used solely by the purchaser in the AMIS context, for the purpose of providing a transmission path between two VM systems. Such circuits are also called "TIE" lines.
"Destination System"--A system to which a message or control information is being sent.
"DTMF"--Dual Tone Multi-Frequency. The method of signalling in which each digit or symbol is uniquely represented by a standard combination of two tones. Each tone is comprised of two frequencies from one of two exclusive groups. For AMIS, the required tones are 0-9, *, #, C, and D.
"Frame"--A unit of information transferred, normally containing data plus control information in the form of an "envelope" of DTMF tones. There are two basic AMIS frame types, Data and Response, as defined in the AMIS Analog Specification.
"International Direct Distance Dialing (IDDD)"--The international form of Direct Distance Dialing. An IDDD number consists in its full form of a Country Code (CC) plus the National Significant Number (NSN). The NSN in turn consists of a trunk code (equivalent to the U.S. Area Code) and Subscriber Number. The maximum length of the CC plus NSN is twelve digits. The current maximum length of the CC alone is three digits. The IDDD number is the normal way of identifying a "System Number", as defined hereinafter
"Inter-Vendor Networking"--The mechanisms by which systems produced by different manufacturers network with each other. This is a key objective of the AMIS.
"Mailbox"--A logical abstraction referring to the locations in the system in which a recipient's messages are stored, and which are seen by a recipient as a single logical storage area.
"Mailbox ID"--The portion of an AMIS Analog Protocol address in a message that identifies the mailbox of the originator/recipient, consisting of 1-16 digits.
"Message"--A generic term referring to the audio information sent over a VM system network.
"Open Access"--Refers to the ability of a user on one AMIS system to send messages to a user on another AMIS system, and the recipient user to send a reply back to the originator, without any prearranged configuration of the respective systems, such as the exchange of passwords.
"Originator"--The user who initiates a voice message (also called the Sender). Where necessary, the AMIS Analog Protocol distinguishes between the user and his/her system, referring to the latter as the "Originating" (or Sending) System.
"PSTN"--Abbreviation for the public switched telephone network.
"Receive"--One of the basic AMIS Analog Protocol messaging functions. The function by which a destination system accepts a message and stores it in the mailbox of the intended recipient.
"Recipient"--The user who receives a voice message. Where necessary, the AMIS Analog Protocol distinguishes between the recipient and his/her system, referring to the latter as the Destination System.
"Reply"--One of the basic AMIS Analog Protocol messaging functions. The function in which a message recipient may respond to the message without having to input the originator's address.
"Send"--One of the basic AMIS Analog Protocol messaging functions. The function in which a message originator directs the originating system to send a message to a designated recipient.
"Session"--A single connection between voice message systems, during which one or more messages, with accompanying protocol information, are transmitted from the originator to the intended recipient; also referred to herein as an "AMIS Analog Message Delivery Session".
"Subscriber"--Another name for a User with a mailbox on a system.
"System Number"--The portion of an AMIS Analog Protocol address that identifies the originating system. It consists of the International Direct Distance Dialing (IDDD) number by which the system can be reached over the PSTN, with variations to handle special cases such as private network dialing.
"User"--A person utilizing a voice message system; in the AMIS connection, a person who is executing AMIS-visible actions (e.g., Send or Receive) on a message.
3. Description of the Prior Art
Voice messaging ("VM") has become a service that users of all sizes and disciplines have come to rely on as a critical communications tool. Voice messaging is an application that allows customers to record and distribute voice messages to one or more voice mailboxes for retrieval by the destination party or parties. The user enters the VM system, records a message, specifies message delivery options and recipient addresses based on the available features of the particular VM system, and exits the system. The VM system then delivers the recorded message to the recipients' mailboxes, and in some cases notifies the recipients of the waiting message.
The voice messaging industry has advanced significantly in the last few years. One aspect of that advancement has been the emergence of VM system networking, which extends the voice messaging capabilities beyond the boundary of a single VM system by providing transfer of messages between VM systems. Networking allows an organization to more efficiently and effectively transfer information via voice messaging throughout an organization. For example, VM system networking may link several departments of a large institution, branch offices with corporate headquarters, or small offices in geographically dispersed locations.
Until recently, a given VM system network has involved only systems produced by a single vendor. There is, however, a growing need for the networking of multiple vendors' systems. For instance, as corporations grow though acquisitions, they may find that the companies they have acquired utilize voice messaging systems from different vendors. In other cases, the individual departmental VM system purchases, made before the need for corporate-wide networking was apparent, have led to the purchases of different vendors' systems which must later be made to network. Additionally there is a growing need for corporations to extend their networking boundaries to voice messaging users in other companies. Finally, service providers are also beginning to implement service to individual users that will expect networking with other users in much the same way the public telephone network links them together today.
The Audio Messaging Interchange Specification (AMIS) describes how different vendors' systems can network. Two different AMIS protocols have been developed, responding to a perceived dichotomy in the needs of the voice messaging industry; an AMIS analog networking protocol and an AMIS digital networking protocol.
With a digital scheme, both control signaling and message transmission are done in digital form. To address the needs of small system users and vendors, an alternative analog protocol specification has been developed. The previously described AMIS Analog Protocol uses Dual-Tone, Multifrequency (DTMF) signaling, and message transmission in analog form.
It is in VM networks which support the analog protocol version of the AMIS, that the present invention finds application. Accordingly, the remainder of this background section will focus on the AMIS Analog Protocol per se and desirable features for incorporation in systems supporting the AMIS Analog Protocol.
As indicated hereinabove, the AMIS Analog Protocol provides a mechanism for transferring voice messages among VM systems with similar functions, but different architectures and technologies. It provides defined formats for identifying message originators and recipients, addressing messages, and sending, receiving, and replying to messages. Also, as indicated hereinbefore, signaling is done using DTMF tones, and the actual message is transmitted in analog form.
The primary goal of AMIS Analog Protocol was to provide open access networking. Open access means that a user on any VM system that supports the specification can send a message to a user on any other VM system that also supports the specification, and the second user can send a reply message to the first user, without prearranged configuration of the respective systems. The AMIS Analog Protocol is therefore designed for use on the public switched telephone network (PSTN), although it may be used with private TIE lines as well.
Systems may typically access the PSTN via dial-up ports that are addressed using International Direct Distance Dialing (IDDD) telephone numbers (DDD for calls within North America). The use of the established worldwide telephone network ensures universal access.
Another key objective of the AMIS Analog Protocol was to provide a mechanism for meeting the needs of small system users and vendors. Small systems have lower traffic volumes that cannot justify the costs of specialized networking equipment and software. The AMIS Analog Protocol therefore uses analog dual tone multi-frequency (DTMF) control signaling and analog audio message transmission. Since these signaling and transmission capabilities are provided in all common systems, no additional networking equipment is required.
In general, the AMIS Analog Protocol exchange is timing dependent with the protocol itself providing some error checking capabilities.
The protocol also prescribes specific actions to be taken by the supporting VM system network whenever a message is not delivered. The actions taken depend on the reason for the message delivery failure during a given Message Delivery Session. In general, these actions are (1) attempt a redelivery, or (2) return the message and indicate to the user the reason for non-delivery.
Local system characteristics and requirements also dictate what to do if problems are encountered at any time during an AMIS Analog Message Delivery Session; that is, during the performance of any of the well known tasks defined to take place during a Message Delivery Session, namely, during call set up and the protocol data exchange per se (where the protocol data exchange includes actual message transmission).
In particular, the aforementioned PhoneMail implementation of the AMIS Analog protocol requires that statistics associated with AMIS message exchanges be gathered and that a detailed log, which tracks messaging activity, be maintained.
It should be noted that the protocol data exchange used in the illustrative Phonemail network, referred to hereinabove, includes the following well known subtasks: (a) start session data frame transmission/acknowledgement (allowing the originating and destination systems to agree on the version of the protocol being used); (b) originating system ID transmission/acknowledgement (allowing the originating system to identify itself to the destination system and enabling the destination system to screen calls and send replies); (c) message information transmission/acknowledgement (enabling message specific information which indicates message destination and source to be exchanged; and which also provides the destination system with information necessary to determine whether a target mailbox can accept messages); (d) actual message transmission from the originating system to the destination system, including receipt acknowledgement; and (e) sign off (for terminating the session).
In the illustrative PhoneMail context, if a single message scheduled for delivery encounters a problem (such as a busy line, full mailbox, etc.) at any time during the Session (call set up or protocol exchange, including message transmission), a status signal is generated. It should also be noted that a status signal is generated by PhoneMail whenever a message is successfully delivered.
It should be further noted that, in accordance with the AMIS Analog protocol, VM systems such as Phonemail allow for the possibility of sending two or more messages after the AMIS Analog Message Delivery Session communications link is established by the call set up process. In this environment at least one status signal is generated for each message.
In the illustrative PhoneMail context in which the invention is being described, a Message Delivery Session that includes the scheduled delivery of two or more messages, may continue after the failure to deliver a given message so long as no redelivery action (i.e., a retry at delivering the failed message) is indicated by the protocol or locally defined rules.
For example, in the PhoneMail context, attempting to deliver a message to a full mailbox would result in a failure to deliver the message and a prompt would be used to inform the sender of the failure condition; however, in this situation, no retry (redelivery attempt) is called for in PhoneMail and the Message Delivery Session can continue if there are more messages to deliver.
In the PhoneMail context, a specified retry action results in the Message Delivery Session ending with the failed message. This would happen, for example, when a framing error is encountered. In fact, in the PhoneMail context (being described in some detail herein for the sake of illustrating an environment in which the invention finds utility), the retry process assumes that the Message Delivery Session during which the failed message was to be delivered, has ended.
In view of the many different types of actions (for example, playing a prompt, attempting to redeliver a message, logging statistics, etc.), that may be required depending on the reason that a given status signal is generated, it would be desirable to provide methods and apparatus for easily identifying reasons for the generation of the status signal, measuring the progress of a given Message Delivery Session, initiating associated actions required by the AMIS Analog protocol, and coordinating and controlling other activities specific to the particular VM system being used (such as PhoneMail) to implement the AMIS Analog protocol.
Furthermore, it would be desirable to provide methods and apparatus which facilitate the development of VM systems (like PhoneMail) that support the AMIS Analog protocol. As indicated hereinbefore, there are many reasons AMIS message delivery may be unsuccessful and each may require a different set of actions. When designing a software architecture to implement the set of required actions, separate software elements (usually implemented by different individuals) make it important to provide a mechanism for coordinating and controlling the execution of such elements to avoid operating errors and to use computing resources efficiently.
Furthermore, should protocol specifications change or new protocols be introduced for support by existing VM systems, it would be desirable to provide methods and apparatus which facilitate supporting, coordinating and controlling any new actions required by the revised or newly introduced protocol, where the actions are to be taken in response to the generation of the aforementioned (or revised) status signals associated with Message Delivery Session activity.